home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 2 / ETO Development Tools 2.iso / Tools - Objects / MPW C++ 3.1 / Examples / CPlusExamples / ShapesAppCommon.h < prev    next >
Encoding:
C/C++ Source or Header  |  1990-09-11  |  6.8 KB  |  179 lines  |  [TEXT/MPS ]
  1. /*------------------------------------------------------------------------------
  2. #
  3. #    MultiFinder-Aware Simple Shapes Sample Application
  4. #
  5. #    CPlusShapesApp
  6. #
  7. #    This file: ShapesAppCommon.h - Common Header (C++ and Rez) for ShapesApp
  8. #
  9. #    Copyright © 1988 Apple Computer, Inc.
  10. #    All rights reserved.
  11. #
  12. #    Versions:    1.0                 3/89
  13. #
  14. #    Components:
  15. #            CPlusShapesApp.make        March 1, 1989
  16. #            TApplicationCommon.h    March 1, 1989
  17. #            TApplication.h            March 1, 1989
  18. #            TDocument.h                March 1, 1989
  19. #            ShapesAppCommon.h        March 1, 1989
  20. #            ShapesApp.h                March 1, 1989
  21. #            ShapesDocument.h        March 1, 1989
  22. #            TApplication.cp            March 1, 1989
  23. #            TDocument.cp            March 1, 1989
  24. #            ShapesApp.cp            March 1, 1989
  25. #            ShapesDocument.cp        March 1, 1989
  26. #            TApplication.r            March 1, 1989
  27. #            ShapesApp.r                March 1, 1989
  28. #
  29. #   There are four main classes in this program. Each of
  30. #   these classes has a definition (.h) file and an
  31. #   implementation (.cp) file.  
  32. #   
  33. #   The TApplication class does all of the basic event
  34. #   handling and initialization necessary for Mac Toolbox
  35. #   applications. It maintains a list of TDocument objects,
  36. #   and passes events to the correct TDocument class when
  37. #   apropriate. 
  38. #   
  39. #   The TDocument class does all of the basic document
  40. #   handling work. TDocuments are objects that are
  41. #   associated with a window. Methods are provided to deal
  42. #   with update, activate, mouse-click, key down, and other
  43. #   events. Some additional classes which implement a
  44. #   linked list of TDocument objects are provided. 
  45. #   
  46. #   The TApplication and TDocument classes together define
  47. #   a basic framework for Mac applications, without having
  48. #   any specific knowledge about the type of data being
  49. #   displayed by the application's documents. They are a
  50. #   (very) crude implementation of the MacApp application
  51. #   model, without the sophisticated view heirarchies or
  52. #   any real error handling. 
  53. #   
  54. #   The TShapesApp class is a subclass of TApplication. It
  55. #   overrides several TApplication methods, including those
  56. #   for handling menu commands and cursor adjustment, and
  57. #   it does some necessary initialization.
  58. #   
  59. #   The TShapesDocument class is a subclass of TDocument. This
  60. #   class contains most of the special purpose code for
  61. #   shape drawing. In addition to overriding several of the
  62. #   TDocument methods, it defines a few additional
  63. #   methods which are used by the TShapesApp class to get
  64. #   information on the document state.  
  65. #
  66. #------------------------------------------------------------------------------*/
  67. #ifndef ShapesAppCommon_Defs
  68. #define ShapesAppCommon_Defs
  69.  
  70. /*
  71.     These definitions are shared by Rez and C++. We use #define statements
  72.     instead of constants in this file because Rez doesn't support constants.
  73.  */
  74.  
  75. /*    Determining an application's minimum size to request from MultiFinder depends
  76.     on many things, each of which can be unique to an application's function,
  77.     the anticipated environment, the developer's attitude of what constitutes
  78.     reasonable functionality and performance, etc. Here is a list of some things to
  79.     consider when determining the minimum size (and preferred size) for your
  80.     application. The list is pretty much in order of importance, but by no means
  81.     complete.
  82.     
  83.     1.    What is the minimum size needed to give almost 100 percent assurance
  84.         that the application won't crash because it ran out of memory? This
  85.         includes not only things that you do have direct control over such as
  86.         checking for NIL handles and pointers, but also things that some
  87.         feel are not so much under their control such as QuickDraw and the
  88.         Segment Loader.
  89.         
  90.     2.    What kind of performance can a user expect from the application when
  91.         it is running in the minimum memory configuration? Performance includes
  92.         not only speed in handling data, but also things like how many documents
  93.         can be opened, etc.
  94.         
  95.     3.    What are the typical sizes of scraps that a user might wish to work
  96.         with when lauching or switching to your application? If the amount
  97.         of memory is too small, the scrap will be purged from memory. This
  98.         can be quite frustrating to the user.
  99.         
  100.     4.    The previous items have concentrated on topics that tend to cause an
  101.         increase in the minimum size to request from MultiFinder. On the flip
  102.         side, however, should be the consideration of what environments the
  103.         application may be running in. There may be a high probability that
  104.         many users with relatively small memory configurations will want to
  105.         avail themselves of your application. Or, many users might want to use it
  106.         while several other, possibly related/complementary applications are
  107.         running. If that is the case, it would be helpful to have a fairly
  108.         small minimum size.
  109.     
  110.     What we did for CPlusShapesApp:
  111.     
  112.         We determined the smallest heap size that CPlusShapesApp could have and
  113.         still run (48K). For the preferred size we added enough space to permit:
  114.             a. a little performance cushion (see 2, above) (12K)
  115.         Result: 60K for preferred size
  116.         
  117.         Result: 48K for minimum size
  118. */
  119.  
  120. #define kPrefSize                60
  121. #define kMinSize                48
  122.     
  123. /* kMinHeap - This is the minimum result from the following
  124.      equation:
  125.             
  126.             ORD(GetApplLimit) - ORD(ApplicZone)
  127.             
  128.      for the application to run. It will insure that enough memory will
  129.      be around for reasonable-sized scraps, FKEYs, etc. to exist with the
  130.      application, and still give the application some 'breathing room'.
  131.      To derive this number, we ran under a MultiFinder partition that was
  132.      our requested minimum size, as given in the 'SIZE' resource. */
  133.      
  134. #define    kMinHeap                 (34 * 1024)
  135.     
  136. /* kMinSpace - This is the minimum result from PurgeSpace, when called
  137.      at initialization time, for the application to run. This number acts
  138.      as a double-check to insure that there really is enough memory for the
  139.      application to run, including what has been taken up already by
  140.      pre-loaded resources, the scrap, code, and other sundry memory blocks. */
  141.      
  142. #define    kMinSpace                (20 * 1024)
  143.  
  144. /* id of our STR# for error strings */
  145. #define kShapesAppErrStrings     129
  146.  
  147. /* The following are indicies into STR# resources. */
  148. #define    eNoMemory                1
  149. #define    eNoWindow                2
  150.  
  151. #define    rMenuBar    128                /* application's menu bar */
  152. #define    rAboutAlert    128                /* about alert */
  153. #define    rDocWindow    128                /* application's window */
  154.  
  155. /* The following constants are used to identify menus and their items. The menu IDs
  156.    have an "m" prefix and the item numbers within each menu have an "i" prefix. */
  157. #define    mApple                    128        /* Apple menu */
  158. #define    iAbout                    1
  159.  
  160. #define    mFile                    129        /* File menu */
  161. #define    iNew                    1
  162. #define    iClose                    4
  163. #define    iQuit                    12
  164.  
  165. #define    mEdit                    130        /* Edit menu */
  166. #define    iUndo                    1
  167. #define    iCut                    3
  168. #define    iCopy                    4
  169. #define    iPaste                    5
  170. #define    iClear                    6
  171.  
  172. #define    mShapes                    131        /* Shapes menu */
  173. #define    iRRect                    1
  174. #define    iOval                    2
  175. #define    iArc                    3
  176. #define    iMove                    5
  177.  
  178. #endif ShapesAppCommon_Defs
  179.